UTRAN (Universal Terrestrial Radio Access Network) is a term that identifies the radio access network of a UMTS (Universal Mobile Telecommunications System), wherein the UTRAN consists of Radio Network Controllers (RNCs) and NodeBs i.e. radio base stations. The NodeBs communicate wirelessly with mobile user equipments and the RNCs control the NodeBs. The RNCs are further connected to the Core Network (CN). Evolved UTRAN (E-UTRAN) is an evolution of the UTRAN towards a high-data rate, low-latency and packet-optimised radio access network. Further, the E-UTRAN consist of eNodeBs (evolved eNodeBs), and the eNodeBs are interconnected and further connected to the Evolved Packet Core network (EPC). E-UTRAN is also being referred to as Long Term Evolution (LTE) and is standardized within the 3rd Generation Partnership Project (3GPP).
In LTE, an uplink Media Access Control (MAC) scheduler resides in the eNodeB and assigns transmission resources to user equipments in the cell. Furthermore, the eNodeB selects the Transport Format (TF) to be used by the user equipment. In order to perform these tasks the MAC scheduler needs information about the UEs current buffer states, i.e. if and how much data the UE buffers in its priority queues. The MAC scheduler may also need further information such as the available power headroom and the transmit power used to estimate uplink gain to select a suitable TF. Very precise and up-to-date scheduling information allows accurate scheduling decisions. However, providing this information from the UE towards the eNodeB comes at a certain cost which must be compared to the gain it offers.
A detailed buffer status report may be quite large in number of bits and if transmitted frequently would cost considerable overhead. For many applications the buffer status is continuously changing. For example, Transmission Control Protocol (TCP) continuously increases its congestion window but when experiencing a packet drop it decreases the congestion window. For the applications utilizing the TCP a rough buffer indication that is frequently updated is more useful.
Buffer status reporting is being standardized in 3GPP. Buffer status reporting is performed by the UE to report to the eNodeB the amount of data available for transmission stored in its buffer. The eNodeB utilizes the buffer status reports to allocate resources to the UE and to prioritize resource allocation between the UEs in a cell.
LTE is compatible with the OSI layered reference model for both the UE part and the E-UTRAN part. The protocol architecture is subdivided into the control plane, responsible for the transmission of signaling information, and the user plane, responsible for the transmission of user data. FIG. 1 shows the protocol stack for the user plane in LTE. In particular, three protocol layers are considered: the Physical Layer (layer 1), the Data Link Layer (layer 2) and the Network Layer (layer 3). The layer 2 protocols include the Media Access Control (MAC) protocol, the Radio Link Control (RLC) protocol, and the Packet Data Convergence Protocol (PDCP). The layer 2 structure for uplink is shown in FIG. 2. The MAC performs buffer status reporting. The RLC provides radio link management for the radio interface. The PDCP hosts the header compression, the reordering functions and the ciphering functions as illustrated in FIG. 3.
As stated in the 3GPP standardization document TS 36.323, the LTE supports compression of Internet Protocol (IP) headers in the PDCP. The header compression protocol is based on the Robust Header Compression (RoHC) framework, RFC 4995. RoHC compresses 40 bytes or 60 bytes of overhead typically into only 1 or 3 bytes by placing a compressor before the link that has limited capacity and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the opposite.
There are multiple header compression algorithms, called profiles, defined in the RoHC framework. Each profile is specific to the particular network layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP (Real-time Transport Protocol/User Datagram Protocol/IP).
However, the compression ratio achieved by the header compression algorithm depends on a number of factors, including:                the change behaviour of the data fields in a sequence of packets from one packet to the other e.g. the IP Identifier behaviour, or the typical inter-packet increase in sequence numbers and timestamps,        the state of the compression context,        possible impairment over the link carrying the compressed packets, e.g. losses, reordering, feedback requesting context repairs, and        implementation-specific factors, such as robustness algorithms, e.g. the number of repetition of the same type of update, feedback logic, and the subset of compressed headers supported etc.        
Because of these factors, the compression ratio that is possible to achieve cannot be determined ahead of the compression process itself for one specific packet. Thus, the exact amount of bits that needs to be transmitted between the UE and the eNodeB is known only after header compression has been performed.
Furthermore, the RLC can be configured to operate in different modes, e.g. Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). RLC-TM functions include the transfer of user data. RLC-UM functions include the transfer of user data, segmentation and reassembly functionalities and sequencing. The RLC-AM provides reliability through retransmission. RLC-AM functions include transfer of user data, segmentation and reassembly functionalities, error correction, duplicate detection, protocol error detection and recovery. The RLC-AM includes an Automatic Repeat Request (ARQ) function that provides error correction for services requiring higher transmission reliability, such as packet-switched data services. However, in RLC-UM mode the RLC does not perform ARQ and consequently some RLC SDUs (Service Data Units) may be lost.
When a UE performs a handover from one cell to another, e.g. intra-eNodeB handover or inter-eNodeB handover, for radio bearers configured with RLC-AM, the UE cumulatively retransmits all PDCP SDUs starting from the sequence number corresponding to the oldest PDU that has not been acknowledged by RLC prior to the handover indication. A radio bearer that is configured with RLC-AM can also be configured to use a PDCP status report. The PDCP status report is used at handover for the PDCP SDUs that where not successfully received before the handover; this can be used by the receiver of the report to avoid sending duplicates to the target eNodeB after the handover.
Furthermore, at handover both ciphering and header compression are restarted. Thus, in order to transmit PDCP SDUs in the target cell, a new security context and a new header compression context must be used. Consequently, as both security and header compression are restarted, any data buffered in the RLC layer become useless and is thus discarded. If data available for transmission is buffered below the PDCP layer, i.e. header compression and ciphering have both been performed on the buffered data, the UE must still have the means to access the uncompressed and unciphered data in order to compress and cipher the data based on the new respective contexts at handover. Otherwise, the data is lost when the RLC buffers are cleared. On the other hand, if data available for transmission is buffered above the PDCP layer header compression and ciphering have not yet been performed on the buffered data. In the case when header compression is configured, the UE can only report the uncompressed amount of data buffered in its buffer and the buffer reporting is thus not accurate. It should be noted that the UE normally processes data only in the TTI (Transmission Time Interval), in which the data is sent. Thus, data may be buffered below the PDCP layer and above the PDCP layer.
Moreover, active queue management (AQM) can be performed to drop packets from the queue when the amount of data being buffered for transmission exceeds the capacity of the UE to store and transmit the data. It is normally preferable to perform AQM before the PDCP layer for IP flows with a higher packet rate in order not to negatively impact the PDCP functions, e.g. to avoid loss of security/header compression synchronization.
In the state of the art buffer status reporting mechanism the UE always report either:                1) the size of uncompressed data,        2) a size of data that approximates the size of the compressed data, based on an estimation of the compression ratio, or        3) the size of compressed data.        
However, in case of 1), i.e. the size of uncompressed data is reported when header compression is configured, the reported size of data will not be accurate as explained previously. In case of 2), i.e. the size of data that approximates the size of the compressed data is reported, the reporting will be inaccurate because the compression ratio is not deterministic and cannot be predicted accurately. Additionally, in order to perform the estimation it introduces complexity. In case of 3), i.e. the size of compressed data is reported, it is implied that either a UE performs header compression of all data as soon as the data arrives in the PDCP layer, or it cannot produce a report for some of the data. It is expected that the UE will process data, e.g. perform header compression and ciphering, only at the time of transmission in order to take into account any change in the compression state i.e. changes due to timers or feedback, and to minimize memory requirements. The UE must maintain an uncompressed copy of the compressed PDCP SDU in some cases, e.g. when RLC AM is configured, as otherwise some data might be lost when the RLC buffers are reset for example when handover is executed.
As mentioned previously, the eNodeB uses the buffer status report received from the UE to allocate radio resources to the UE to meet service requirements, to avoid UE buffer overflowing as well as stop allocating resources to the UE when the UE has no more data to transmit. Without buffer status reports, or with inaccurate buffer status reporting wherein the size of reported data in the UE buffers is larger than what will actually be transmitted, the eNodeB will allocate more resources than needed by the UE and lead to that the UE transmits padding for the grants already issued to the UE. In case the size of the reported data in the UE buffers is smaller than what is actually transmitted, the eNodeB will allocate too little resources which will lead to segmentation and increased transmission delays.
How significant the error in the buffer status reporting is depends on the size of the IP payload with respect to the size of the uncompressed header. If the UE always reports the status of its buffer based on the uncompressed size of data and header compression is configured, the reported size of data will be entirely inaccurate. For data services where the size of the payload in the IP packet is small and comparable to the size of the uncompressed header, e.g. Voice over IP, pure TCP acknowledgements, then the error will be quite important, e.g. roughly 50% for Voice over IP/AMR12.2 with RoHC compression, otherwise the error may be less significant.